This invention relates to networked data storage and in particular to target side recognition and host page routing table update, as adapted for use with Multi-Path Input Output (MPIO) or similar protocols.
As computer users rely more and more on access to remote stored information such as for databases, web applications, e-commerce, online transaction processing, and the like, the amount of remotely located information that needs to be managed and stored increases as well. The management of this information continues to provide challenges to information system administrators.
While standard disk servers are quite capable of storing data, their capacity is limited. They can also become a bottleneck if too many users try to access the same storage device at the same time. In one traditional approach to solving this problem, a large number of storage devices are attached to a single network server. A network administrator can then create a “farm” of such servers for a given application.
However, as server farms increase in size, and as companies rely more heavily on data-intensive applications, even this storage model is not completely useful. Recently, a number of vendors have collaborated to develop so-called Storage Area Network (SAN) technology. SANs provide more options for network storage, including much faster access than peripheral devices that operate as Network Attached Storage (NAS). SANs further provide flexibility to create separate networks to handle large volumes of data.
A SAN is a high speed special purpose network that interconnects different kinds of data storage devices with associated data servers on behalf of a larger network of users. A SAN can be clustered in close proximity to other computing resources, but may also extend to remote locations using wide area network technologies such as Asynchronous Transfer Mode (ATM), Fiber Channel, Internet Small Computer Systems Interface (iSCSI), and the like.
SANs typically support disk mirroring, backup and restore, archival and retrieval of archived data, data migration from one storage device to another, and the sharing of data among different servers. SANs can also incorporate subnetworks within network attached storage systems.
Certain improvements have been developed to SANs such as those described in U.S. Patent Publication No. 2004/0143637, entitled “Adaptive Storage Block Data Distribution”, hereby incorporated by reference in its entirety. That design allows a storage area network administrator to control how data is stored and managed without requiring a gateway to monitor all incoming request traffic. The specific systems described in that patent application provide block level data storage services in an iSCSI environment, for example. Such a service may be employed to partition the available data storage across a plurality of equivalent servers (also called “targets” in iSCSI terminology). Each of the equivalent servers presents a similar interface to a client (called “initiators” in iSCSI terminology) and each equivalent server presents the same response to the same request from the client. Each server can also therefore communicate with other servers to notify each other when responsibility for certain data blocks is moved from one server to another server.
To maintain an understanding of the location of different data blocks across different partitions and across the different disk volumes maintained by the data block storage system, each equivalent server maintains a routing table. To this end, each equivalent server executes a routing table process that tracks the different data blocks being stored on the data block storage system and the particular equivalent server that is responsible for each data block. Changes to the routing table can be propagated by the routing table process. More particularly, since the location of the data blocks may change from time to time, routing tables need to be updated to reflect these changes.
In that system, the routing table thus shows which parts of a given volume (which page) reside on which server; each of the servers is considered a member of a particular group of servers. However, the routing tables do not necessarily list all members of a group, and tracking group membership isn't a function of the routing tables.
“MPIO” as implemented in certain versions of Microsoft™ Windows has recently emerged as a solution for providing higher availability and higher performance storage area connectivity, with the so-called multi-path I/O protocols. Multi-path Input/Output (MPIO) is a server, network, and storage configuration that allows for multiple physical connections between a host computer and target storage array. The benefit of this configuration is increased availability via multiple redundant communication paths, and improved performance by simultaneously making available for use all available paths.
Using MPIO, storage arrays can support multiple network connections and networks can be configured to support multiple physical connections. Host systems can also have multiple initiator processes. MPIO can work in many standard operating system configurations such as stand-alone systems and clusters.
Implementation of MPIO is somewhat complex, however, in that multi-path software, initiators, network elements and storage array software must all work together to provide a robust solution. A deficiency in any component can cause the solution not to meet requirements for high availability, quick recovery, and high performance operation.
MPIO solutions have historically been implemented such that each storage array vendor has a custom software solution. This creates a configuration management burden on the end user in the event that the end user desires to deploy different solutions.
Microsoft has recently developed its own Multi-Path I/O framework for use within Windows™ environments. The Microsoft MPIO architecture allows multiple storage systems to share the same MPIO solution. This framework allows, for example, multiple physical device objects to be joined together into a single functional device object called an “MPIO disk”. This framework, however, requires storage vendors to create a Device Specific Module (DSM) for each product in order to “claim” physical objects as a single functional object.
In one standard MPIO solution, the server (the “iSCSI target”) is capable of recognizing such MPIO disk structures. This is supported by having the DSM change iSCSI port names such as, for example, using vendor specific SCSI op codes so that all connections of an MPIO disk share a common SCSI port name.
However, there are at least several problems even with this approach:
1. This information alone cannot be used to provide load balancing among multiple physical connections. Thus, it is not possible to spread connections from a single MPIO disk over all volume members, nor is it possible to even locate two connections on the same interface of a single volume member. In other words, an attempt to load balance cannot take into account a situation where ideally one would spread the set of connections across other available disk volumes. In the event of a network failure, multiple connections might be on a common physical path that has failed, but this path cannot be deleted. It would be better to spread the available connections away from one another across all available physical paths.
2. In addition, the standard DSM does not always receive notification from the higher level MPIO process that an iSCSI connection has been reestablished. In this scenario, iSCSI reservations will not work correctly, which means that clusters will also not operate correctly.